home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 2⁄16⁄90 / 0054-Re C++ access questi-Feb90 < prev    next >
Encoding:
Text File  |  1990-02-16  |  1.7 KB  |  41 lines  |  [TEXT/GEOL]
  1. Item    0178267                         14-Feb-90        23:10PST
  2.  
  3. From:   D3632                           Cadence Design, Ken Friedenbach,PRT
  4.  
  5. To:     D4695                           Skywalker Sys, Scott Collins,PRT
  6.  
  7. cc:     CPLUS.DEV$                      C++ Interest List--Developers
  8.  
  9. Sub:    RE-C++ access question
  10.  
  11. Dear Scott and Neal,
  12.  
  13. Your "bug?" looks more like a "bug fix!" to me!
  14.  
  15. The bug (in early versions of 2.0) was that member functions were given
  16. access to the private members of "this" object, but not to other
  17. instances of the same class, such as parameters, or locally declared
  18. variables.  This bug may have made "private" seem like "private to an
  19. object".  But in fact, it was always intended to be "private to a class".
  20.  
  21. Consider the "private loop-hole" or "export" mechanism: the "friend"
  22. keyword.  A "friend" of a class has access to the private members
  23. of ANY variables of the class: global variables, parameters, or local
  24. variables.  There is no way to say "friend of arg1, but not of arg2",
  25. or "friend of the args, but not of global variables".
  26.  
  27. The private/protected/public keywords are intended to support safer
  28. Software engineering practice, by restricting the scope (or amount of
  29. text) which can refer to the private members of ANY object of the class.
  30. They are not intended to support correct design and implementation by
  31. modifying access to individual objects of a class.  (Although that would
  32. be nice!).  The private/protected/public form of protection is better
  33. than none, but not the ultimate imagineable.
  34.  
  35. Ken Friedenbach
  36.  
  37. P.S.  Under your interpretation it would make sense to declare a member
  38. function as a friend of the class, to get access for objects other than
  39. "this".
  40.  
  41.